Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/spwg/spwg-minutes-90july.txt

Text File | 1993-02-17 | 20.0 KB | 516 lines

CURRENT_MEETING_REPORT_


Reported by Steve Crocker/TIS, Richard Pethia/CERT,
J. Paul Holbrook/CERT

SPWG Minutes

The Security Policy Working Group (SPWG) met in Vancouver.  The Chair,
Richard Pethia, was unable to attend, and the meeting was co-Chaired by
Paul Holbrook and Steve Crocker.

Background

Prior meetings had opened up a range of topics including whether there
should be a security policy for the Internet, what aspects of security
were important, who should implement the policy, and what means should
be used.  A three dimensional framework had been proposed to help
categorize the issues.  The three dimensions are:

Security services, including:


   o Protection of information from unauthorized disclosure
   o Protection of information from unauthorized modification
   o Protection from denial of service
   o Protection from unauthorized use of facilities


Who is affected


   o Users
   o Host operators
   o Local network operators
   o Regional and Backbone network operators
   o Host operating system vendors
   o Network component suppliers, e.g., router vendors


Means to implement


   o Administrative
   o Technical
   o Legal and Legislative


The Vancouveri Meeting

At the Vancouver meeting, we shifted focus and attempted to find a

                                   1






consensus on what the central elements of an Internet policy might be.

The group engaged in an experiment in which each participant attempted
to write a set of principles.  This exercise worked very well, and the
responses from the group showed a surprising amount of agreement.  Joel
Jacobs from Mitre took the task of trying to synthesize the writings of
the group into a single strawman security policy.  A summary (and
interpretation) of some of the thoughts of the group is included at the
end of these minutes.

A fuller summary of the exercise conducted at the Vancouver meeting will
be coming out in October.  Some points emerged fairly clearly.  There is
a common understanding that sites are fundamentally reponsible for their
own security and that in a community as large as the Internet there are
some individuals who will attempt to violate the security of systems.
Against this backdrop, two ideas emerged fairly clearly as principles to
build into the policy.


  1. Users have a positive obligation to respect the security of the
     systems on the Internet.  This includes not attempting to penetrate
     systems they don't have access to and not exceeding the authorized
     use of the systems they have access to.  As simple as this
     statement seems to be, it establishes the idea that security in the
     Internet is not a game.  Without a clear statement along these
     lines, it might be considered fair game to try to break into
     systems just to see if it can be done.
  2. Sites and network operators should cooperate with each other on
     security matters.
     Again, this statement seems simple on its face, but it establishes
     the idea that sites, local nets, etc., have an obligation to assist
     each other instead of leaving each site strictly to its own
     defense.


These ideas and others will be elaborated upon in the next few months.

Selected Observations

What follows are some of the themes the group seems to agree upon
coupled with explanatory paragraphs in which I (Paul Holbrook) try to
interpret the thinking of the group.

A caveat:  the information in this document has been filtered several
times.  Steve Crocker provided the original bullets, and thus provided
his own view of what the group said.  The paragraph after each bullet is
my interpretation of what the group was thinking about.  In particular,
where the explanation says people `should' do something, that does not
mean that everyone agreed to propose this, just that this is one
interpretation of where the group was going.  The result is that the
people who were at the meeting may not agree with what follows.


                                   2






Internet, regionals/backbones, sites, hosts -- all should have security
policies.

Security policies and procedures are needed at all levels of the
Internet.  The policies will be different for different groups, and the
general level of security expected may be different.  For example, the
policy may encourage regional networks to protect the network
infrastructure such as the routers and other network equipment, but may
put the burden of privacy on hosts.  Thus, a regional would make it's
best effort to protect the network, but would not provide a guarantee of
privacy for the hosts that use it.

Emphasis on user responsibility, identification, and accountability.

The policy should state clearly that users are responsible for their own
actions regardless of the level of security a site maintains.  By
analogy, even if you leave your front door unlocked, that doesn't give
someone else permission to enter your house.

Sites should also have policies that support identifying and (if
necessary) accounting for individual users.  If your site is used to
break into another site, that other site may ask for your help in
tracking down the problem.  It should be possible for you to figure out
what user's account at your site was used.  This requires that all users
be individually identified, and that enough accounting records be kept
to identify when users were on systems.  (On Unix systems, the normal
login accounting may well be sufficient for what we're after here.)

This last requirement is likely to be controversial.  There are sites
that keep guest or group accounts for their own convenience, terminal
servers that allow access out to the Internet without logging into a
local system, and so forth.  There was some irony in this proposal,
since we all enjoyed this kind of open access out to the Internet at
UBC, yet this was the very kind of access we were proposing limiting.

Emphasis on mutual assistance

   o Preference for investigation
   o Concern for privacy

Where possible, sites should assist each other in investigating security
incidents.  Sites should provide contact points to help facilitate
communication about security problems.

When a security incident occurs, a site has two main choices:


   o Try to watch or trace the intruder(s) in an effort to see how
     widespread the problem is and hopefully identify who is
     responsible;
   o Identify the vulnerabilities or lapses that led to the incident,
     clean up the systems and lock the intruder(s)

                                   3






Some people leaned towards encouraging sites to investigate problems.
In many cases, locking an intruder out will force them to find another
site to use, but will not stop them from breaking into systems.  The
decision about what to do about an intrusion will always be up to the
site, but the community standard should be to try to solve the problem.
This does not necessarily advocate prosecution or law enforcement
involvement.  Once an intruder is identified, there are many possible
courses of action.

Encouragement to use good security controls

Policies and procedures are not a substitute for putting good security
controls in place and making sure systems are securely configured.  The
policy should encourage sites to put useful security controls in place.

The_Need_for_Unforgeable_User_Identification_

Vint Cerf/CNRI

FIRST DRAFT

Summary

This brief memorandum motivates the need for Internet mechanisms and
facilities for authenticating user identification and for assuring that
such identification cannot be forged.

Introduction

The Internet has reached a point in its evolution where some of the
services accessible require compensation from the using parties (or an
entity which accepts responsibility for paying for services rendered).

At the application level, such compensation is required for use of
information services such as bibliographic databases (National Library
of Medicine MEDLARS; Research Libraries Information Network, etc.)

Commercial electronic messaging providers (e.g.  MCI Mail, Compuserve,
ATT Mail, Sprint Mail, BT Dialcom, QUIK-COMM, etc.)  normally charge for
their services.  Some, such as Compuserve and MCI Mail provide access to
commercial information services (e.g., Dow Jones News & Retrieval).
Under the present terms and conditions, commercial email services do not
charge Internet users for delivering email sent from Internet sites to
commercial email boxes.  Even if this provision remains in place, there
are other services such as fax and hardcopy delivery, bulletin boards
and information services which, at present, are not accessible to
Internet users because there is no secure way to identify a billable
account to which to charge these special services.

Passwords carried in plaintext form across the Internet, whether in a
Telnet session or via email, are not sufficiently protected to make the

                                   4






risk of compromise acceptable.  Moreover, there is no currently
standardized means of authenticating whether the use of a particular
billable account is legitimate (once a password is compromised, it can
be used at will, for simple, password-based account identification
methods.)

Example Requirements

At least two applications need reliable, secure account authentication
capability:

   o Remote login
   o Email store and forward services

In the first instance, it is required that the user/account
identification provided to the server be protected from capture and
re-use by hostile third parties and that the serving site can verify
that the identification has not been forged.

In the second case, it is required that at an email relay, an arriving
message to be passed into the next email system can be reliably and
authentically associated with an account in the next email system, if
necessary, for purposes of accounting and validation that the message
originator is authorized to use the services requested.

For example, it should be possible for an Internet user to send email to
fax recipients by way of ATT Mail and for ATT Mail to correctly account
and bill for this usage.  This means that the originator must supply
information associated with a message which identifies account
information needed to complete processing of the message at the
Internet/commercial email interface.  The provision of this account
identifying information needs protection from compromise and validation
that its use is legitimate.

Questions


  1. Can the same techniques work for remote login and store-and-forward
     services?
  2. Even if a ``password'' can be encrypted for confidentiality and
     signed for authenticity, how can the recipient be sure that the
     encrypted and signed object has not been hijacked by an abusing
     third party?  (i.e.  ``stealing and reuse'')
  3. Given that there must be some kind of authenticated exchange
     between user and server just to set up an account, can we take
     advantage of this to carry out any additional exchanges needed to
     support the confidentiality and authenticity required for these
     account validation applications?


Scope_of_the_Internet_Security_Policy_


                                   5






J. Paul Holbrook/CERT/SEI/CMU:
This proposal deals with two areas that the Internet Security Policy is
concerned with:  the scope of the Internet Policy, and lines of
authority or responsibility at a site.  These are separate issues, so
I'll treat them that way.

Scope of the Policy

The Internet Security Policy should not mandate security policies for
sites beyond what is necessary for maintaining the security of the
Internet.  The policy should not mandate the form of a site's internal
response to security problems.  However, it should require that a site
have policies in place which meet a minimum set of requirements to allow
effective prevention of and response to Internet security problems.
Helping a site develop a more complete set of security policies and
procedures is the goal of the the Site Security Policy Handbook.

The goal of the policy is to ensure that each site responsibly protects
and audits access to the Internet, and maintains a point of contact so
that each site can get information about security problems and also
assist others in dealing with security problems that involve their site.

The policy covers all ``network-capable'' devices that may affect the
Internet.  Thus, in addition to hosts, terminal servers, routers, and
other network management devices are covered.  Other machines that may
indirectly allow unaudited access to the Internet are also covered.  For
example, if a host that has access to the Internet also trusts other
hosts on a site's local network, the policy covers those other machines
as well.  As an example, if an Internet host trusts a local PC via some
mechanism such as rlogin or special trusted accounts, a user might be
able to use the PC to gain access to the Internet without proper
auditing.  In this case, the PC is covered under the policy.  (If the
Internet host does not trust the PC, the PC does not come under the
policy.)

Site Authority

In this proposal, I use the term `site' to mean every resource-owning
organization, including regional networks and other entities.  I've used
the terms `MUST' and `SHOULD' in capitals to help point out suggested
policy directions.



     [Comments in brackets are notes to help explain the reasoning
     behind some of the statements.  These comments would not appear
     as part of a policy, though they might appear as a commentary
     that goes along with the policy.]



Site Security Contact

                                   6






Every site MUST have a site security contact.  This may or may not be
the same as the normal site contact or network manager.  A site security
contact can be an individual or an organization.  The site security
contact SHOULD be familiar with the technology and security of all
systems at that site.  If that is not possible, the security contact
MUST be able to get in touch with the people that have this knowledge 24
hours a day.


     [At the CERT we've been in touch with sites only to find out
     that they have no idea who is responsible for security or how
     to get in touch with them.]
     [A point of terminology:  in his `responsibility' writeup,
     James VanBokkelen refers to `network managers' and `host
     managers'.  The site security contact is a peer to the network
     manager; it might even be the same person.  Others in the
     Internet community have used the term `site contact', which
     I've used because it helps to emphasize that a site security
     contact may have to deal with both network and host issues.
     Certainly a regional network or other network provider can (and
     should) have a `site security contact.'  However, the
     terminology is certainly open to change.]


Security Contact Availability

The site security contact MUST provide other designated organizations in
the Internet with a 24 hour point of contact.  At a minimum, this should
be a phone number which is answered during `business hours' 5 days a
week, and equipped with an answering machine that is checked at least
once every day (including weekends) to cover off hours.  Sites SHOULD
consider providing `real time' response:  e.g., home phone numbers,
pager numbers, or other means of contacting people.  However, being able
to get directly in touch with the security contact at any time is not
required.


     [This is a compromise statement; it's hard to require a site to
     provide around-the-clock response without proof that it would
     be worth the cost.  At the CERT we've found almost all problems
     can be dealt with by having a contact who is available during
     business hours.  However, large sites or sites that care about
     the availability and security of their systems will probably
     want to provide 24 hour access to their security contact.]


Sites MUST ensure that some backup security contact can be reached if
the primary security contact is unavailable.  This can take the form of
a secondary contact person or organization.  If outside organizations
must use some different procedure to get to the backup security contact,

                                   7






sites MUST ensure that these procedures are communicated to the outside
organizations.

The `designated' or `outside' organizations have this contact
information might be a local Network Control Center or Network
Information Center, or might be security response centers such as CERT.
Since security organizations might need access to this information
anytime, organizations that keep this information MUST make it available
24 hours a day.


     [ The User Connectivity Problem (UCP) Working Group is working
     on the problem of how to get site contact information
     propagated around so that network problems can be dealt with.
     We should consider using whatever means they come up with for
     distributing this kind of information.  In any case, the
     specifics of how this works are an operational matter that
     doesn't belong in a policy.  ]


Security Policy Issues

Although the initial response to a security incident is often a
technical one, policy issues also need to be dealt with.  Should an
intruder be shut out or watched?  Should law enforcement be involved?
Should a site disconnect itself from the network to avoid a worm or
intruders?  These decisions are not strictly technical; they may affect
many people.  Sites MUST ensure that people with the authority to decide
these kinds of issues are available in the event of a serious security
problem.

If the site security contact does not have the authority to make these
kinds of decisions, sites are encouraged to have a 24 hour
administrative contact.  (This administrative contact does not need to
be visible to people outside the site.)  Sites SHOULD also have policies
that state who has the authority to make decisions and take actions in
response to security problems, and under what circumstances
administrators or decision makers should be brought in on an active
security incident.  The goal should be that a site security contact can
quickly (i.e., in a few hours) take action to deal with a security
problem, if necessary getting in touch with someone who can authorize
their actions.

At some sites, policy makers could give advance authorization to the
site security contact and other system managers.  For example, the site
may give their technical people the authority and license to make their
best efforts to deal with security problems.  In this case, the policy
also protects the technical people from `retribution' from policy makers
after the fact.


     [The motivation here is that policy makers should be involved
     early on if a serious security incident is underway.  Policy

                                   8






     makers may have little to do with the day-to-day operation of
     systems, but they will be concerned if a serious security
     incident has serious impact on a site and it's operation.
     Among other things, if decision makers are not involved and
     understand the nature of security problems, they might impose
     policies after the fact to `deal with the security problem.'
     For example, the CERT has heard of sites where the local policy
     maker's response to a security incident was to advocate
     permanently disconnecting from the Internet.
     However, since this issue is mostly a matter of site internal
     policies, the Internet Security Policy should not mandate an
     administrative contact.  The Site Security Policy Handbook will
     help flesh out this area by going into detail about how site
     policy makers should be involved in setting security policy and
     procedures.]


Attendees


Alison Brown             alison@[e-mail]
Steve Crocker            [e-mail]
Terry Gray               [e-mail]
J. Paul Holbrook         [e-mail]
Greg Hollingsworth       [e-mail]
Joel Jacobs              [e-mail]
David Jordan             [e-mail]
Tim Seaver               [e-mail]
Mark Stein               [e-mail]
Dale Walters
John Wieronski           [e-mail]
C. Philip Wood           [e-mail]



                                   9